Technical Field
This application relates generally to secure network-based communications using cryptographic protocols such as SSL.
Brief Description of the Related Art
Distributed computer systems are well-known in the prior art. One such distributed computer system is a “content delivery network” or “CDN” that is operated and managed by a service provider. The service provider typically provides the content delivery service on behalf of third parties (customers) who use the service provider's infrastructure. A distributed system of this type typically refers to a collection of autonomous computers linked by a network or networks, together with the software, systems, protocols and techniques designed to facilitate various services, such as content delivery, web application acceleration, or other support of outsourced origin site infrastructure. A CDN service provider typically provides service delivery through digital properties (such as a website), which are provisioned in a customer portal and then deployed to the network. A digital property typically is bound to one or more edge configurations that allow the service provider to account for traffic and bill its customer.
Secure Sockets Layer (SSL) is a well-known cryptographic protocol that is used to secure communications over networks such as the Internet. Cryptographic protocols such as SSL are often based on public key cryptographic systems, such as the RSA (Rivest, Shamir and Adelman) encryption algorithm. For a traditional RSA-based SSL session, the two sides of a connection agree upon a “pre-master secret” (PMS) which is used to generate the parameters for the remainder of the session. Typically, the two sides use RSA asymmetric encryption to establish the pre-master secret without exchanging the actual value in plaintext. In operation, the SSL client generates the pre-master secret and encrypts it with the SSL server's publicly available RSA key. This generates an encrypted pre-master secret (ePMS), which is then provided to the SSL server. The SSL server has a private decryption key, which is then used to decrypt the encrypted pre-master secret. At this point, both the client and the server have the original pre-master secret and can use it to generate the symmetric key used for actual encrypted and secure data exchange.
Decrypting the encrypted pre-master secret is the only time in the SSL connection that the private key is needed. This decryption occurs at a so-called SSL termination point. In many instances, the SSL termination point is insecure, and thus the storage and use of that key there presents significant security risks.
To address this problem, it is known to provide an Internet infrastructure delivery platform (e.g., operated by a service provider) provides an RSA proxy “service” as an enhancement to the SSL protocol that off-loads the decryption of the encrypted pre-master secret (ePMS) to an external server. Using this service, instead of decrypting the ePMS “locally,” the SSL server proxies (forwards) the ePMS to an RSA proxy server component and receives, in response, the decrypted pre-master secret. In this manner, the decryption key does not need to be stored in association with the SSL server.
In one system embodiment, such as described in U.S. Publication No. 2013/0156189, at least one machine in a first network-accessible location includes an RSA proxy server software program, and at least one machine in a second network-accessible location includes an RSA proxy client software program. The RSA proxy server software program and the RSA proxy client software program each include code to establish and maintain a secure (e.g., a mutually-authenticated SSL) connection there-between. The RSA proxy client software typically executes in association with an SSL server component (such as OpenSSL). According to this disclosure, however, SSL decryption keys are not accessible to the RSA proxy client software. Rather, decryption of encrypted pre-master secrets is off-loaded to the RSA proxy server software program. In operation, the RSA proxy client software program receives and forwards to the RSA proxy server software program over the mutually-authenticated SSL connection an encrypted pre-master secret associated with a new SSL handshake request received (at the RSA proxy client) from an end user client program (e.g., an SSL-enabled web browser, a native mobile app, or the like). The RSA proxy server software program decrypts the encrypted pre-master secret using a decryption key that is maintained at the RSA proxy server software program and not otherwise accessible to the RSA proxy client software program. The RSA proxy server software program then returns a decrypted pre-master secret to the RSA proxy client software program over the mutually-authenticated SSL connection. The end user client program and the SSL server component both are then in possession of the pre-master secret (and can use it to generate the symmetric key used for encrypting the connection between them).
Optimally, the RSA proxy server component has good security, and there is an encrypted and authenticated bi-directional communication channel with the RSA proxy client component to communicate the requests. If, however, security of the RSA proxy client component cannot be fully assured (or the server on which this component executes is compromised), an individual (or computing entity) who had been watching and recording communications between the requesting client and the RSA proxy client component could gain access to the archived encrypted streams. This malicious third party entity would do this by simply forwarding captured ePMS's along to the RSA proxy server component, which might then decrypt them as if the request were coming from the intermediary, thereby potentially allowing the malicious third party to gain access to the stream's contents. An observer also might be inclined to represent to the RSA proxy server component that the intermediary has succumbed to a break-in; upon learning this untruth, the RSA proxy server component might then simply sever all communications and no longer decrypt ePMSs on the RSA proxy client component's behalf. Even if audit protections are in place to protect against such schemes, time may pass before any such break-in is detected and during which valid decryptions can be requested on behalf of the bad actor.
The subject matter herein addresses this problem of the ePMS decryption request itself potentially being a vector for defeating forward secrecy.